Traditionally, automated board testing involved functional test wherein input signals were provided to the external inputs of a board and output signals were observed from the external outputs of the board. This type of functional testing, however, can become very complicated for complex circuitry and can provide only limited diagnostics. Modern testing increasingly supplements this traditional functional test with the efficient, flexible in-circuit test. In-circuit test is a type of functional test wherein the performance of each digital integrated circuit (IC) on a board is independently tested as a functional unit.
In order to perform in-circuit test, a tester must apply input signals directly to the inputs of the DUT (device under test or test generation) and must access the outputs of the DUT to observe the output response. A "bed-of-nails" (i.e., probes that directly make contact with the device I/O pins from pads on the surface of the board) fixture is used to provide access to the required nodes on the board. Each digital IC can then be tested as if it were electrically isolated from the circuit. As a result, tests for many common digital IC's can be programmed once, in advance, stored in a library, and then called upon when needed. This greatly simplifies test generation since this pre-programmed test can be used over and over again.
In-circuit testing is conventionally performed on an ATE (Automated Test Equipment) system. An ATE system (tester) 100 is shown in FIG. 1. ATE system 100 includes a test generator 102 and a test controller 104. Test generator 102 generates an in-circuit test for each device on a board to be tested. A generic test plan 106 provides supervisory control over testing. This includes sequencing the tests, logging the result, controlling board/fixture interfacing, controlling the test power supplies, and providing a user interface. The combination of the individual in-circuit tests and test plan 106 forms a board test specification. A device models library 108, physical database 110, and an electrical database 112 provide the data required for test generator 102 to generate the in-circuit tests. Electrical database 112 contains a list of the devices on the board, an electrical description for each device, and electrical interconnect information. Physical database 110 contains a topological description of the board which will be used by test controller 104 to locate and test DUT 116. Physical database 110 and electrical database 112 are typically generated by a CAD/CAM (Computer Aided Design/Computer Aided Manufacturing) system during design of a board.
Device models library 108 contains a plurality of pre-generated generic models for commonly used digital integrated circuit chips (IC's). Essentially, each model is a test routine which is to be inserted (i.e., edited) into the board test specification. Each device model provides, for a specific device, pin-out information (i.e., which pins are inputs, outputs, bi-directional, or usused), a test program, a method for pre-conditioning (described below) each output of the device, and device specific information including a test pattern rate and required signal levels. When devices which are not in device models library 108 are encountered, a model may be manually entered into the tester and, if desired, the models library.
Test controller 104 executes the in-circuit tests generated by test generator 102. A driver module 114 is used to apply the test signals to a DUT 116, and a sensor (receiver) module 118 is used to receive the response of DUT 116 to the test signals. The combination of driver module 114 and sensor module 118 is known as a tester channel.
The HP3070 tester is an example of an ATE system. The HP3070 is available from Hewlett-Packard Company, Palo Alto, Calif. Detailed operational information for the HP3070 is contained in "HP3070 Board Test System User's Documentation Set (1989)" available from Hewlett-Packard under HP part number 44930A.
While in-circuit test is based on testing each digital IC as if it were isolated from the surrounding devices, in reality, true electrical isolation cannot occur because of existing device interconnections. Consequently the application of an input signal to a DUT is often in conflict with the quiescent state of that input by virtue of its coupling to an upstream output. An "upstream" device is a device whose output is driving an input of the DUT. Upstream output and upstream device are used interchangeably herein.
In order to provide the required input to the DUT, it may be necessary to back-drive or over-drive the output of the upstream device. That is, the upstream output must essentially be overwhelmed so that the tester controls the node between the input of the DUT and the output of the upstream device. This involves forcing a reverse current through the upstream output or sinking a current sourced by the upstream output in order to overcome its quiescent state.
Back-driving digital IC's can cause a plurality of test problems. These include:
1. INSUFFICIENT BACK-DRIVE CURRENT--As discussed above, the ATE system will change the logic state of an upstream output by overwhelming it. Some testers, however, may have insufficient drive capabilities to accomplish this for some devices. For example, if an output at a logical LOW state is to be forced HIGH, then the tester must source sufficient current to force the output transistor of the upstream output out of saturation. The current required to accomplish this can exceed the tester capabilities for certain devices (e.g., Advanced Schottky TTL devices, which are capable of sinking high currents) such that the tester cannot back-drive these devices. PA1 2. COMPONENT DAMAGE - Some digital devices have sensitive outputs which may be damaged by being back-driven. The damage may result from current flow, temperature rise, or voltage over/undershoot. The damage may include immediate failure or simply a degradation in the device's life. PA1 3. COMPONENT OSCILLATION--Attempts to back-drive an output of an integrated circuit which has feedback may result in a sustained oscillation. This will produce unpredictable test results, and may further result in damage to other devices which are connected to the node.
For a more detailed discussion of in-circuit testing and associated back-drive problems, see U.S. Pat. No. 4,588,945 to Groves et al.
Known test methods deal with these problems by pre-conditioning (or simply "conditioning") devices upstream from a DUT. Each output which is to be back-driven is conditioned. Conditioning involves placing the output to be back-driven in a state that can be easily/safely back-driven. The conditioned device/output will then be left in that state throughout the test. For example, the ASTTL device discussed above would have its output placed in a logical HIGH state (for TTL logic it is easier to pull a logical HIGH down to a logial LOW that it is to drive a LOW to a HIGH).
Conventional conditioning is performed either manually or automatically by the ATE. For manual conditioning, a test engineer will identify specific devices which require conditioning and then modify the test to provide conditioning for these specific devices. This method is slow, tedious, and can require a large amount of a test engineer's time. In addition, because the determination of which devices to condition is made at test, the test fixture (which is often fabricated simultaneously with the circuit board) may have to be modified. Modification of the test fixture is costly and can result in test delays.
Many conventional testers provide an automatic upstream condition option. If upstream conditioning is enabled, then all upstream devices will be conditioned. The convention is to key on the DUT, and to condition devices upstream therefrom. Once enabled, conditioning is performed regardless of whether it is required.
The conventional method for generating (at test generator 102) an in-circuit ATE test (with conditioning enabled) for a circuit board is shown in FIG. 2. The data required includes electrical databases 112 and device models library 108.
At step 208, a device (DUT) is selected for test generation from electrical database 112. At step 212, the test generator gets an electrical description of the DUT from electric database 112 and a test method for the DUT from device models library 108. The inputs of the DUT which will be driven during test are determined at this point. Then, at step 214, electrical interconnected data from electrical data 112 is used to identify all device outputs which will be back-driven in order to test the DUT. A list of these outputs to condition is created at step 216.
The test statement required to condition the outputs is written at step 220. Finally, at step 222, the in-circuit ATE test 224 is written for the DUT. Writing the test involves retrieving a generic test for the DUT from device models library 108 and then merging the conditioning test statement from step 220.
Note that since upstream conditioning is enabled, all upstream devices (the number of levels upstream to condition may be selected) are conditioned. The convention is to key on the DUT, and to condition devices upstream therefrom. The conditioning is performed regardless of need for many devices. The result is a large amount of superfluous conditioning. For large circuits, this can severely complicate both the test and the test fixture by requiring access to an inordinate number of circuit nodes.
In addition to complicating testing, performing a large amount of unnecessary conditioning may be impractical or even impossible due to exhaustion of tester channels and/or conditioning conflicts. Conventional ATE systems have a finite, relatively small, number of tester channels (driver/receiver resources), and too often, a test engineer finds that too few tester channels are available to meet his testing needs. Further, conditioning a large number of devices often leads to conflicting (e.g., mutually exclusive) conditioning methods.
Thus, given that carte blanche conditioning is not always possible and that tester channel resources must be used in an efficient manner, a fixed number of upstream levels to condition is normally selected (e.g., condition all back-driven outputs within four levels upstream form the DUT). This arbitrary cut-off for conditioning, however, exacerbates the problem rather than solving it because now even more upstream outputs are being back-driven. For example, if conditioning is selected for N levels upstream, then the devices N+1 levels upstream are being back-driven without conditioning.
A sample circuit 300 is shown in FIG. 3. Gate G1 is the DUT. In order to test G1, gates G2-G5 will be back-driven. If gates G2 and G8 have sensitive outputs which require conditioning, then a test engineer may either manually make this determination and modify the test to condition G2 and G8, or he may enable conventional upstream conditioning as described above. In order to condition G2 or G8, upstream conditioning must be enabled for two levels upstream from the DUT. This will cause twenty outputs (G2-G21) to be conditioned, requiring access to sixty-four modes. Thus, while conditioning was necessary for only two devices (e.g., G2 and G8), twenty devices are conditioned. As discussed above, an immense test problem is created.
An additional difficulty which plagues conventional in-circuit test is that of "problem" or interfering outputs/devices. These are devices which, if not disabled, will adversely affect or interfere with the test of another device (i.e., the DUT). Test problems causes by problem devices can be difficult to locate because the problem device can affect a remotely located and tenuously associated DUT.
Problem devices include noisy devices, such as oscillators. The "problem" with oscillators is that an output carrying the oscillating signal may not be reliably back-driven. An attempt to back-drive the output may result in a noisy plagued by transients. In addition, the oscillating signal can be propagated through several devices to affect a downstream DUT. Thus, to ensure reliable test results, problem devices must be conditioned. "Conditioning" when applied to problem devices often means disabling the device such that it cannot interfere with testing.
The conventional method for dealing with a problem device is to wait until a problem occurs during test, and to then diagnose the problem and remedy it. This method is, however, manpower intensive, can result in test delays, and can require modification of the test fixture.
What is needed is a method for selectively conditioning only devices which require conditioning, and for making the determination of which devices to condition an automated function of test generation. Also needed is a method for spotting problem devices during test generation and for integrating conditioning for the problem devices into the test for any affected devices.